CentOS 7 (OpenVZ): network not starting after reboot — [fix]
A CentOS 7 container (OpenVZ) that loses networking after a reboot is a painful but fairly common incident: the interface is not brought up, routes are missing, DNS fails, and remote access disappears. This can happen after updates, template changes, or when the host-side virtual network mode changes. The goal of this guide is practical: regain connectivity, identify what exactly failed (interface, network service, config files, or DNS), apply a reliable fix, and make sure it survives the next reboot.
If you run production workloads where predictable network behavior matters, consider the underlying platform choice. For a more modern isolation model and flexible networking, many teams prefer Virtual Servers. For guaranteed resources and full hardware control, there are Dedicated Servers. For simpler websites that do not require custom OS networking, Hosting can be a better fit.
Key principle: first get console access (provider panel, container console, or any out-of-band method), then diagnose. OpenVZ containers have nuances: some network behavior is managed by the host and containers do not behave exactly like full VMs. That’s why the fix is often about aligning your CentOS network scripts with the actual interface name and ensuring services are consistent.
1) Quick diagnosis: does the interface exist and is it up?
After reboot, connect through console access and run “ip a”, “ip link”, and “ip r”. In OpenVZ you might see eth0, venet0, or veth0 depending on the configuration. If the interface exists but is DOWN, the network service might not be bringing it up (or ONBOOT is not enabled). If the IP address is missing, the ifcfg configuration might be wrong or overridden.
Check service status and logs: “systemctl status network” and “journalctl -u network -b”. If you see errors like “device not found”, that often means the ifcfg file’s DEVICE name does not match the real interface (for example ifcfg-eth0 but the container uses venet0). This mismatch is one of the most common causes of network not starting after reboot.
Also confirm whether you have a default route. Even if the interface has an IP, a missing default route means the container cannot reach outside networks. “ip r” should show a default route via the provider gateway. If it doesn’t, check the GATEWAY setting or provider-side network configuration.
2) The classic fix: correct ifcfg files and restart networking
On CentOS 7, traditional network configuration lives in /etc/sysconfig/network-scripts/. Find the ifcfg file that corresponds to your interface. Verify: DEVICE, BOOTPROTO, ONBOOT, IPADDR, NETMASK or PREFIX, GATEWAY, DNS1/DNS2. The critical one for reboot persistence is ONBOOT=yes.
If you use a static IP, confirm IPADDR and GATEWAY are correct. In OpenVZ, the gateway is often a host-side router value provided by your hosting provider. If you set the wrong gateway, the interface may come up but nothing outside will work. Always confirm the default route exists after applying changes.
# example: /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=203.0.113.10 PREFIX=24 GATEWAY=203.0.113.1 DNS1=1.1.1.1 DNS2=8.8.8.8
After editing, run “systemctl restart network” and re-check “ip a” and “ip r”. If available, you can also do “ifdown eth0; ifup eth0”. In OpenVZ, interface types may not be Ethernet in the classic sense, but the network scripts often still work as long as DEVICE names match the actual interface.
If you were trying DHCP, confirm that your provider actually supports DHCP for that container. Many server deployments use static addressing; if DHCP is not available, the network service can appear stuck while waiting for a lease that will never arrive. This becomes common after migrations between nodes or after template changes.
3) NetworkManager conflicts: pick one management model
CentOS 7 often ships with NetworkManager. In server environments—especially inside OpenVZ containers—it can conflict with the classic “network” service. If NetworkManager grabs the interface, it may ignore your ifcfg settings or apply a different profile after reboot.
If “network” claims success but the IP is missing, check “systemctl status NetworkManager”. If it is active and managing your main interface, consider disabling it and relying on the classic network service. Do this only when you have console access, because changing network managers can drop your session if done incorrectly.
4) DNS failures that look like “no network”
Sometimes routing and IP are fine, but DNS is broken. Test this with two pings: “ping 8.8.8.8” and “ping google.com”. If the IP ping works but the domain ping fails, you have DNS trouble, not general networking trouble. Check /etc/resolv.conf and your DNS settings in ifcfg (DNS1/DNS2). In some OpenVZ setups, resolv.conf can be overwritten, so make sure your DNS settings persist across reboots.
Also consider firewall rules. In some cases firewalld or iptables can block DNS or other traffic after updates. Check “systemctl status firewalld” and review rules if you recently installed or modified firewall packages inside the container.
5) OpenVZ specifics: venet vs veth and host-side changes
OpenVZ can use venet (routed, no L2) or veth (virtual Ethernet). If the host changes the mode, the interface name and behavior inside the container can change. That is why the DEVICE name in your ifcfg files must match what “ip link” shows after reboot. A mismatch breaks automatic startup.
In some environments, IP addressing and routes are pushed from the host side. If you cannot set a persistent IP inside the container, check the provider control panel or host configuration. In that case, your best fix may be to revert to a minimal compatible configuration that doesn’t fight provider-managed settings.
Post-fix verification and prevention
After applying a fix, verify systematically: (1) “ip a” shows the correct IP; (2) “ip r” shows a default route; (3) ping the gateway; (4) ping a public IP; (5) ping a domain name to confirm DNS; and (6) reboot again to confirm the issue does not return. A second reboot test is the real proof that your configuration is persistent.
For prevention, keep network config simple, avoid mixing NetworkManager and classic network scripts, and back up working ifcfg files before major updates. If you frequently need predictable networking after reboot and more flexible control, consider moving workloads to a VM/VPS model where the OS networking stack is fully under your control and not partially constrained by container virtualization.